DSML development: a UML profile based approach

Jean-Michel Bruel
jbruel@gmail.com
27/10/2014

To follow the slides on Internet…​

http://bit.ly/jmb-idm2014 
http://bit.ly/jmb-idm2014
http://jmbhome.herokuapp.com/teaching/idm2014/main.html
http://jmbhome.herokuapp.com/teaching/idm2014/main.slides.html
git clone https://github.com/jmbruel/idm2014

Plan

  1. Demo
  2. Process
  3. Explanations and details

About Papyrus

  • eclipse-based editor for UML

    • Complete UML 2.5 specificiation support
    • SysML™ 1.2, MARTE 1.1, …​

  • Tool for defining UML-based DSLs

    • UML profiles
    • Support for customizability
    • Open, robust, highly scalable
    • Model-Driven Egineered (written using Papyrus itself)

  • More details:

    PapyrusLogo256x256
    Figure 1. https://www.eclipse.org/papyrus/

About the modelers

People from CEA-List involved in this case study (special thanks):

Project involvment (3.5 days):

  • metamodel + profil ⇒ 1d
  • customization ⇒ 2d
  • example farming model ⇒ 0.5d

Process:

  • confcall with client
  • documents and screen capture
  • synchro/discussions with Benoit
  • use of common repo (github)

Profile-based approach

  • What is a profile?
  • General process
  • Concrete example

What is a profile ?

  • Abstract syntax for a new language

    • Set of stereotypes
    • Set of OCL constraints

What is a profile ?

profile JT

General process

profil BS

General process

Step #1

Starting from the expected DSL (most of the time a modelsc or a graphical représentation) and a description of the domain model (modelmde)

input

General process

Step #2

A domain modelmde is more precisely defined (e.g. a class diagram such as [mm1])

step1

Structural metamodel

image001

Functional metamodel

image002

General process

Step #3

The concepts (e.g., Farm in [mm1]) are mapped to the more suitable UML elements (e.g., Class in [profile1])

step2

General process

image003

General process

Step #4

If the concepts directly match UML concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., [profile1])

Step #5

Else another solution (e.g., defining a metamodel from scratch) should be studied.

crossing

Working on the concrete syntax

Step #6

It is time then to "customize" the DSML to make it as close as possible as the user domain representation.

dsml

Additional definitions

image004

Defining the domain model

Note

There are different ways of defining the domain model:

  • the domain expert provides the domain model (e.g., UML class diagram)
  • the UML expert translate the concepts from the stakeholders into a domain model
  • the UML expert and the domain expert build a modelmde as close as possible of the expected DSL and the UML expert extract the core concepts in a domain model

Iterative process

The above process is iterative. The constructs are introduced by step. The profile is experimented in a modelsc importing the profile so that the user can validate that the concepts are captured adequatly. This is were the UML expert can use tuning possibilities.

Improvements

The next steps can consist in:

  • defining a dedicated diagram
  • providing a wizard for the new language
  • defining a specific property view (File ▸ New …​ Property View Configuration and then right click on the generated property)

  • Working on the concrete syntax:

    • customizing the styles (look & feel)
    • customizing New ▸ Child
    • customizing the Model explorer
    • packaging together the profile, the property view, the palette, etc.

Improvements

Tip
  • Papyrus provides a DSML Configuration plugin to help on these steps.

  • There is also the possibility of defining a Feature that group together a set of profiles

    wizard

Example of work on the concrete syntax

Let us illustrate the need for a specific concrete syntax.

  • (starting from Structural and Functional Domain Models)
  • (and from the profile)

  • using the profile in examples

    • Farm structure
    • Activities descriptions

Structural Domain Model

FarmingDomainModelStucture

Functional Domain Model

FarmingDomainModelFunctional

Structural profile

FarmingProfileStructure

Functional profile

FarmingProfileFunctional

Using the profile: Farm structure

FarmStructure

Using the profile: Papyrus context

ModelingInterface

Crop Workshops description

CropWS

Activity description (UML Activity Diagram)

CornActivity

Activity description (UML Activity Diagram)

WheatActivity

Customizing the Model Explorer

ModelingInterfaceZoomModelExplorer

Customizing the Palette (structure)

ModelingInterfaceZoomPalette1

Customizing the Palette (activities)

ModelingInterfaceZoomPalette2

Customizing the Palette (property view, structural element)

ModelingInterfaceZoomPropertiesView1

Customizing the Palette (property view activity element)

ModelingInterfaceZoomPropertiesView3

Animation and external tools coupling

moka1

Animation and external tools coupling

moka2

Animation and external tools coupling

moka3

Conclusion

Profile definition

  • in terms of stereotypes (extending metaclasses)
  • adding specific properties to the stereotype (e.g., period in this figure)
  • adding OCL constraints

Main differences

  • Using ecore

    • the process consists in starting from scratch, from an empty metamodel
    • the domain model is then define by construction

  • In the UML profile approach

    • we start with an existing (complete) metamodel
    • and the profiling activity consist in restricting it to specific elements

    • the assumption is that their is a benefit in having both additional concepts and tooling, notably in terms of

      • extensibility mecanisms
      • scalability

(honest) Feedbacks

  • Easy tuning and customizing possibilities
  • Almost like doing regular UML modeling
  • UML good knowledge required
  • Not trivial
  • Great work from CEA (3.5 days of work)
  • Need close loop with the client (agile manifesto)

DSML from scratch: the "Wysiwyg approach"

word
  • No constraint on what we type
  • Immediate visualization of the result
  • Possibility to have templates
  • More and mode styles and quality

DSML as UML profiles: the "LaTeX approach"

dsl
  • Constrained language
  • No immediate visualisation of the result
  • Naturally based on templates
  • Rich in libraries and styles
  • Possibilities to see what you get on (almost) real-time
  • Collaborative and user-friendliness improvements

Converging

  • DSML vs Profile-based ⇒ wrong approach
  • DSML or Profile-based ⇒ good question
  • Both Sirius and Papyrus part of Polarsys!
polarsys logo

Thank you for your attention!

width:80%

About…​

Document réalisé par Jean-Michel Bruel via Asciidoctor (version 1.5.1) de 'Dan Allen', lui même basé sur AsciiDoc. Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

Photo credits:

/